The core of the NLB framework is an entity component system (ECS) for creating the elements of a highly interactive and editable building information model (BIM) that is suitable for operational simulation, detailed performance analysis and data mining.

Whilst most ECS favour object composition over class inheritance, this framework integrates both in order to benefit internally from a flexible component structure whilst externally presenting a coherent set of element classes compliant with industry standard BIM data exchange and ISO 19650 information management best practices.

Entities and Components

Entities within the NLB framework represent all the 'things' required to create, edit, view and analyse a building model. Every single one of them is different in some way, but many will likely share some sets of common features and/or behaviours. Thus, it makes sense to try to componentize these commonalities and to develop shared systems for controlling and managing them across all of the different types of entity.

Consider, as an example, entities that may be constructed from a path. Some entities might use that path as a surface boundary whilst others may extrude themselves along it. Either way, the basic concept of a path can be implemented as a component that can be edited and manipulated independently of how the entity subsequently uses it. Moreover, a more complex entity may have other components that also use its path in a variety of different ways. Again, as an example, consider a balcony with a floor slab, ceiling, roof, columns and railings which all use the same path to create themselves.

By implementing each of these as individual components of a single entity, the railing component can quickly identify that it has to sit on top of a floor slab that uses the same path as an edge, and co-exist with columns that also run along it. The railing can then query the floor slab component to find its finished floor level above the path and the column component to find all the surfaces between which it has to span. The floor slab can also quickly identify that it has to support a set of columns, so can query the column component for its dimensions in order to determine how far its edge needs to project outside the path to accommodate it.

Most importantly, by using a path component, the entity management system can quickly search through all the other entities on the same level that have a path component and let each of their path junctions know if they are coincident with others or sit somewhere along the path segments of other entities. This information is critical to many of the balcony's components as they will need to adapt to the other entities around them. For example, the floor slab won't project itself outside any part of its path that is adjacent to another slab. Also the columns and railing can be set to not create instances of themselves where there is an existing wall or other structural support in adjacent entities.

Thus, without having to edit the model in any other way, the balcony entity can be interactively repositioned and/or resized within the model and both it and the entities around it will automatically adapt to the new situation using simple rules and orders of precedence. This is one of the key unique features of the NLB framework as it is designed to allow the entire spatial layout of a building to be quickly and easily rearranged whilst maintaining the integrity and viability of both the geometric and analytical models.

Path Component

This adds a selectable and editable path to the entity for its other components to follow. In addition to the junctions that define them, paths can be open or closed, planar or non-planar, rectilinear or set to always have a vertical normal direction.

Extents Component

This adds an axis-oriented bounding box to the entity which is used by the entity management system as a first-pass test to detect overlapping and/or adjacencies between entities. If the entity also has a path component, the bounding box extents will be automatically updated whenever the path is changed to reflect the geometry of the entity's other components when they are regenerated. If the entity does not have a path component, then the bounding box will be selectable and editable for its other components to scale themselves to.

State Component

This adds a state change option to the entity that its other components can react to. States can vary between two conditions and can do so linearly or via some easing function. Typically the two states are relatively obvious, such as open or closed, on or off, up or down, etc. Internally however, the states themselves have no idea how individual components might use them and simply interpolate between their two extreme values by either switching or animating. They are mainly used by windows, doors, blinds, curtains and other shading devices for their open/closed status, as well as by appliances, equipment, fixtures and fittings for their systems usage.

State components can also be managed by operational schedules to set their values based on the current date and time.

Shell Component

This is typically added to components rather than entities, but adds a faceted shell that can be used to construct and display the external physical form. Pretty well every visible part of a building is the results of rendering a shell component.

Building Elements

The development of BIM applications and standards such as IFC and gbXML have, over time, established a basic set of elements from which building information models can be created and shared. Each of these elements have an expected set of features and behaviours which each part of a common data environment (CDE) must be able to be understand, store and communicate.

Whilst an ECS is used internally to compose and manage these elements, the exposed API is a set of hierarchical classes that closely follow the IFC standard. For example, there are classes for wall, floor, ceiling and roof elements as well as appliances, equipment, fixtures and furniture. Each class has a guaranteed set of components that will always be present in order to understand, store and communicate expected features and behaviours.